這時候...
老闆問我說...改寫..你多久能完成?
我:應該沒機會了....
老闆:這很難嗎?
我:改寫不難...難的是架構有問題....
老闆:............
李組長...讓我們繼續看下去.....
以前的xbase架構
跟現在的架構差異...
不能說不小
沿用相同的資料架構,採用新的設計模式...
會不會讓效率更低?甚至只是持平....
如果只是持平...改幹嘛?
穩定不是很好嗎?
如果翻寫、修改、甚至重構,不能使系統更好...
那....為什麼要做?
iT邦幫忙MVPwiselou提到:
如果翻寫、修改、甚至重構,不能使系統更好...
那....為什麼要做?
不然就不要領薪水啦...
tecksin提到:
不要領薪水
....那就要領失業給付了....
瓜子花生準貝好,戲棚下先卡位再說...
有美眉嗎??...
cdfu提到:
有美眉嗎??...
總 裁 夫 人 駕 到...
iT邦幫忙MVPwiselou提到:
如果翻寫、修改、甚至重構,不能使系統更好...
那....為什麼要做?
同樣的運算邏輯
不會因為開發工具改了而變好!!!
同樣的教授升遷制度
不會因為多了 5年 500疫 而變好
.....
Oracle ERP/ASCP/WIP 系統
同樣抓取資料運算資料方式
不會因為 D2K 變成 JDeveloper 而變好
.......
我們與全球最大資訊服務業
在全台灣最大電腦公司
將整個運算架構完全翻轉
排程模擬 8小時變成 8分鐘
我希望是 8秒鐘
奈何千萬筆料件,千萬個BOM,十萬個工單,
最後還是只能調成 88秒
免強進入秒殺俱樂部
從架構 Oracle / SAP 的最佳顧問
技術轉移顧問
Albert
我們在
全球最大資訊服務業
全台灣最大電腦公司
都有最佳表現績效
各為先進
不吝指教
請
Skype: Adempiere/Compiere
albertachen提到:
重新架構 Oracle / SAP 的最佳顧問
技術轉移顧問
Albert
重新架構 Oracle / SAP 的最佳顧問
技術轉移顧問
Albert
albertachen提到:
各位先進
不吝指教
請
Skype: Adempiere/Compiere
各位先進
不吝指教
請
Skype: Adempiere/Compiere
wiselou提到:
遇到了memory leak...
大概已經到了這開發工具的頂了...不適合繼續發展下去...
這有點令人不解
早期的開發工具是依據早期的硬體環境及作業系統而設計出來的
理論上對記憶體的要求會比現在G來G去的要來得少
有沒有可能是資料量大到一定程度
衝破XBase設計的上限了
FIND...SEEK...
只要REINDEX就能解決一堆問題
多麼令人懷念的美好時光呀
資料量大了..就會遇到2GB的問題...
總之,我也不解...後來解決了...
我只是把某幾個procudure縮短了...
把一些廢話(註解)給砍掉了....
執行檔縮小了...問題就解了...真是見鬼...
albertachen提到:
同樣的運算邏輯不會因為開發工具改了而變好!!!
資料庫也是一樣....感謝指教...
人家都上太空了。你還在相同的邏輯
以前人家的寫法有飯吃,你現在這種寫法只能討飯
以前10000行Code.我怎麼這麼強
現在100行Code,我當初寫的真白痴
pantc328提到:
現在這種寫法只能討飯
連飯都討不到....
貼錯了,重貼
遇到了memory leak...
大概已經到了這開發工具的頂了...不適合繼續發展下去...
這有點令人不解
早期的開發工具是依據早期的硬體環境及作業系統而設計出來的
理論上對記憶體的要求會比現在G來G去的要來得少
有沒有可能是資料量大到一定程度
衝破XBase設計的上限了
FIND...SEEK...
只要REINDEX就能解決一堆問題
多麼令人懷念的美好時光呀
咦?寫完才想到
我根本沒用過 Visual FoxPro
我只用過 DOS 版的 dBase/Clipper/FoxPro
所以
Visual FoxPro 應該跟 FoxPro 差很大才是
antijava提到:
Visual FoxPro 應該跟 FoxPro 差很大才是
有請小狐狸說清楚講明白...
從 PDP-11 .. Wang-VS .. IBM-38..
CP/M M/PM DOS..
dBase I
dBase II
dBase III
Oracle 4/5/6/7/8/9/10/11/12....
Postgres 真好用...
就是這樣
幫你轉到 Postgres
antijava提到:
差很大
差不多啦....
只是多了SQL-92的支援...物件導向的鬼東東....
其他的...差不多耶...
albertachen提到:
Postgres 真好用
這個要請阿伯大開個專欄來寫....
說真的...我只有偷偷摸過它幾次...
對它的特性不清楚...
效能、調教...阿伯大應該可以用這個來參加鐵人賽...
我想....寫這系統的人,應該對VFP的指令不熟....
用了一堆的View以及SQL...
這沒有不對,就是...效能變慢了...很多..
很多資料表的索引都落在...不知道為什麼要放在那個欄位....
例如...索引用A+B欄位...
查詢卻用...SELECT xxx FROM yyy WHERE A=mmm AND B=nnn
這個,在現階段一般的資料庫,沒有不對...
但是...這不符合VFP的索引使用原則...
以FoxPro來說...一個執行檔達到將近20MB....大概也算是怪獸一隻了...
打算先把那些個導致效能不彰的View砍掉....
Form一開啟就載入一大堆莫名其妙的資料
真是...令人不解的寫法...
用了一大堆的JOIN...卻也不幫這些連結鍵建個索引....
整個慢到一個不行....
iT邦幫忙MVPwiselou提到:
慢到一個不行..
iT邦幫忙MVPwiselou提到:
整個慢到一個不行....
想當年呀
下個 PRINT 指令後就可以去抽煙聊天了
多美好呀
後來只要滑鼠點下去就會出現漏斗
不過等待時間大概只剩下能點煙而已
現在搞什麼多工、多核
把電腦搞到快成這副德性
都沒什麼好機會可以休息了
antijava提到:
把電腦搞到快成這副德性
Good Point...所以...我還是讓它繼續垂死就好了....
這樣管這系統的人才有飯吃....
這張圖很適合說明一些情境.
好了...老大說,程式只要不要再當機就好了...慢..就給他去慢吧...
iT邦幫忙MVPwiselou提到:
他
改為 Postgres 好了
iT邦幫忙MVPwiselou提到:
慢..就給他去慢吧...
真的是好主管啊~~~一句就不用重工了.
albertachen提到:
Postgres
我跟MySQL比較熟....
我需要
mySQL 人才
3000 users Login 要調整
導入XenApp就不用重寫了
magician提到:
導入XenApp就不用重寫
不行....軟體都崩潰了...導入什麼Solution會有多大的差別?
直接跑Fatal Error C0000005
經費夠就重構,大家有飯吃.有問題討論起來也比較不會那麼冷門寂寞哦!
讚
分飯給大家一起吃
女王不放飯也很久了...